1. Field of the Invention
This invention relates to the field of cryptography, and in particular to the distribution of private keys in a public/private key pair via a network.
2. Description of Related Art
As the use of networked systems for communication of information increases, and potential access to such networked systems increases, the need for securing communications on the networked systems increases. A number of systems are currently available for encrypting and decrypting messages, and for certifying the originator of a message. An encryption technique that is commonly employed by such systems is one that is based on a public/private key pair technique, such as the RSA (Rivest, Shamir, Adleman) public-key cryptosystem.
In a public/private key pair cryptosystem, a unique public key is generated from a private key using a mathematical technique that is extremely difficult, and practically impossible, to apply in reverse. That is, knowledge of the public key does not facilitate the determination of the private key in a public/private key pair. The public/private key pairs are employed in a corresponding encryption system in such a way that a document, or message, that is encrypted using one of the keys can only be decrypted by the other key. (For the purposes of this document, it is assumed that encrypted messages cannot be decrypted without an appropriate key, even though there may be some finite mathematical possibility that the message may be decrypted by someone without the authorized key.) A public/private key system is termed an asymmetric encryption system, in contrast to a symmetric system, such as Data Encryption Standard (DES) published by the U.S. National Institute of Standards and Technology, wherein the same key is used to encrypt and decrypt a message. Another asymmetric key system common in the art is the ElGamal system, and other symmetric key encryption systems include the IDEA algorithm and the Blowfish algorithm.
In operation, a user of the cryptosystem is assigned a public and private key of a key pair. As its name implies, the public key is intended to be distributed freely by the user, while the private key is intended to be kept secret by the user. When another person wants to send a secure message to the user, the other person encrypts the message using the user""s public key, and then sends the encrypted message to the user. The user decrypts the encrypted message using the user""s private key. Because the encrypted message cannot be decrypted without the private key, the encrypted message can be communicated openly, without fear of being readable by anyone other than the user, assuming that the user has kept the private key secure. If the other person wants to send the same message to multiple users, the other person creates multiple encryptions of the message, using each user""s public key.
Another use of a public and private key pair is authentication. Authentication is a means for verifying the sender of a message. A message is authenticated by encrypting the message using the sender""s private key. When the message is received, the recipient decrypts the message using the sender""s public key. Because the sender""s public key can only decrypt a message that is encoded using the sender""s private key, a successful decryption of the message is an authentication of the sender of the message, assuming that the sender has kept the private key secure.
An alternative authentication method is to encrypt a unique characteristic of the message using the user""s private key. The unique characteristic is a characteristic that changes whenever any changes are made to the message. The user sends the message and encrypted characteristic to another person. The other person applies the sender""s public key to the encrypted characteristic. If the decrypted characteristic matches the unique characteristic of the message, the message is verified as having come from the sender, assuming again that the sender has kept the private key secure.
Although the use of a public/private key pair encryption system provides for a high level of security, the security is highly dependent upon the security measures employed to keep each user""s private key secure. Of particular concern are the processes with which the private key is created, distributed, stored, and retrieved. To assure that the private key is not discernable from the public key, the public and private keys are conventionally very large numbers; for example, RSA utilizes as many as 200 digits. UK Patent Application, xe2x80x9cData communications using public key cryptographyxe2x80x9d, UK serial number GB 2,318,486A, publication date Apr. 22, 1998, filed Oct. 16, 1996 for C. J. Holloway, discloses a method for storing a user""s private key on a server in an encrypted form, for subsequent retrieval and decryption by the user, but specifies that the private key should preferably be generated at the user""s computer (a client processor in a client-server network), to limit the exposure of the private key. In general, the creation of a public/private key pair that is truly secure requires significant computational resources, and a source of a truly random number. To avoid the cost and loss of control that may result by enabling each user in a networked environment to create a public/private key pair, the public/private key pairs are typically generated by an administrator of the network using, for example, a dedicated processor that is physically isolated from the network or other systems. Using this approach, a public/private key pair is distributed to each new user via a secure delivery means, such as a hand-delivered document or diskette containing the public/private key pair. Although less costly than providing the resources to enable each user to generate a public/private key pair directly, the hand-delivery distribution system is awkward, but heretofore required, particularly in a networked environment wherein the communication paths are susceptible to unauthorized or inappropriate monitoring.
It is an object of this invention to provide a method for securely distributing private keys in a network environment. It is a further object of this invention to provide a method for securely storing private keys in a networked environment. It is a further object of this invention to provide a method for securely retrieving private keys in a networked environment. It is also an object of this invention to provide a server processor that facilitates the secure distribution, storage, and retrieval of private keys in a client-server environment. It is also an object of this invention to provide a client processor that facilitates the secure distribution, storage, and retrieval of private keys in a client-server environment. It is also a further object of this invention to provide a client-server system that facilitates the secure distribution, storage, and retrieval of private keys among multiple client processors.
These objects and others are achieved by storing a list of public/private key pairs at the server, wherein the private key is stored in an encrypted form, the encryption being based on a master key. To distribute a public/private key pair to a new user, an administrator who has access to the master key retrieves the next available public/private key pair from the""server at a client processor that is convenient to both the administrator and the new user. At the client processor, the administrator decrypts the private key of the public/private key pair, using the master key, and provides both the public and private keys to the new user. Preferably during this same client session, the new user encrypts the private key, using a password, passphrase, or biometric information that is secret to the new user, and memorable. The private key is immediately erased from the client processor upon encryption with the user""s memorable key. The encrypted private key, the corresponding public key, and an identification of the new user are communicated to and stored at the server for subsequent access by the new user, and potentially others. By employing this technique, the private key is vulnerable to detection only within the client processor, and only for a brief period of time.